FIG. 3 is a block diagram showing an outline of a functional configuration related to a printing process in a host computer as a printing control apparatus which designates printing to a printer 1500 connected to this host computer directly or across a network. The printing process is started when a user of the host computer designates printing from an application 201 such as a wordprocessor program or spreadsheet program.
The application 201 analyzes application data containing character drawing data and the like, and calls a graphic engine 202 provided by an OS (basic software).
The graphic engine 202 loads a printer driver 203 prepared in accordance with the type of the printer 1500, and transfers the output from the application 201 to this printer driver 203. The graphic engine 202 then converts a GDI (Graphic Device Interface) function received from the application 201 into a DDI (Device Driver Interface) function, and outputs this DDI function to the printer driver 203.
On the basis of the DDI function received from the graphic engine 202, the printer driver 203 converts the data into a control command, e.g., a PDL (Page Description Language), which can be recognized by the printer. The converted printer control command is output as printing data from a system spooler 204 to the printer 1500 via an interface 21.
The printer 1500 interprets and expands this control command into bitmap data, and finally outputs the printing result onto a printing medium such as paper.
FIG. 5 is a schematic view showing information necessary for character drawing in the printing process. As shown in FIG. 5, the following information is generally required for character drawing.
Character Code
Character information to be expressed by character drawing. A code based on a predetermined code system such as ASCII, ShiftJIS, or Unicode is used. Some OSs support only a predetermined character code (e.g., ShiftJIS). ShiftJIS has no definitions for British pound (not “£” but a character formed by adding a lateral bar to “L”. In this specification, British pound indicates this character) and a Euro symbol. Therefore, these characters must be expressed by using another character code such as Unicode which supports these characters. If an OS supports only ShiftJIS, British pound cannot be expressed on the OS. An OS uses various means to avoid this event. These means will be explained later.
Font Attributes
Information such as a face name suited to character drawing, the presence/absence of designation of Italic/bald representing modification to a glyph, and the number of points indicating the size of a character.
Font
Information representing the shape of character drawing designated by a face name such as Gothic, Mincho, Times New Roman or Arial. This information contains drawing shape information (called a glyph) of each character. Font information formats are roughly divided into a bitmap font and an outline font, and various formats such as TrueType and OpenType are defined. Internal information of a font will be explained in more detail later.
Drawing Attributes
Information representing the drawing position, color, clip condition, and the like of a character.
If not all of these pieces of information are obtained, character drawing intended by the user is not accomplished. A font is information representing a character drawing shape. However, necessary fonts are not always present in all environments owing to, e.g., the copyright. In other words, a font present in an environment in which a user forms character drawing data may not be present in an environment in which character drawing is performed. As means for performing character drawing with a font intended by a user or with a font having a shape similar to the font intended by the user even if the font intended by the user does not exist in an environment in which the drawing is to be performed, 1) font replacement, 2) bitmap replacement, and 3) font embedding are conventionally known. These means will be explained below with reference to FIG. 7 which shows the drawing results when these means are used.
1. Font Replacement
A method of performing drawing using a font close to font attributes in character drawing data in a character drawing execution environment. Since a font different from the intended font is used, as shown in the upper right row in FIG. 7, a character having a shape entirely different from the one intended by the user maybe drawn. In the worst case, a font corresponding to the intended character code does not exist in a character drawing execution environment, so drawing (printing) which cannot be perceived as a character may be performed.
2. Bitmap Replacement
A method of converting a character into a bitmap when character drawing data is to be formed, thereby converting character drawing into bitmap drawing. This bitmap drawing normally looks the same as character drawing intended by the user. Since the character is drawn as a bitmap, however, the character quality sometimes lowers owing to the influence of the bitmap resolution if the character is enlarged/reduced as shown in the middle right row in FIG. 7.
3. Font Embedding
A method of embedding a font into character drawing data and thereby carrying the font to an environment in which character drawing is actually performed. The embedded font is registered in a character drawing execution environment before character drawing. Therefore, all information is obtained, so character drawing is performed by the format intended by the user. However, when the embedded font is to be registered, caution should be exercised so as not to infringe the copyright. For example, if the embedded font is originally not present in a drawing environment, the registered font must be erased after printing is completed. When printing by an application is completed, therefore, the registered font is discarded from the system so as not to be used by another application. This font embedding has the advantage that an output intended by the user can be obtained even if the designated font does not exist in a character drawing environment. However, character drawing data often increases in size because font information is embedded in the character drawing data. This problem is particularly notable when a font such as a Japanese font having a larger number of character types is embedded.
The operations of the application 201, the graphic engine 202, and the printer driver 203 of the conventional apparatus when character drawing data in which a font is embedded is to be printed will be explained below with reference to a sequence chart shown in FIG. 9.
Step A1. The application 201 notifies the graphic engine 202 via a GDI function that a print job is to be started (the graphic engine 202 converts the notified GDI function into a DDI function and transfers this DDI function to the printer driver 203).
Step Drv1. The printer driver 203 generates a PDL command for job start control.
Step A2. The application 201 notifies the graphic engine 202 via a GDI function that page printing is to be started (the graphic engine 202 transfers the function to the printer driver 203 as in step A1).
Step Drv2. The printer driver 203 generates a PDL command for page start control.
Step A3. The application 201 registers an embedded font in application data into the graphic engine 202. This registration makes it possible to use information of the font essential to character drawing even in this environment.
Step G1. The graphic engine 202 holds the font information.
Step A4. The application 201 performs character drawing by a GDI function using the font registered in step A3 (the graphic engine 202 transfers the function to the printer driver 203 as in step A1).
Step Drv3. The printer driver 203 acquires a glyph of the character by the following processing, in order to generate a character drawing command.
Step Drv3.1. The printer driver 203 issues a character glyph acquisition request to the graphic engine 202.
Step G2. The graphic engine 202 generates a character glyph from the font registered in step G1, and transfers the glyph to the printer driver 203.
Step A5. The application 201 deletes the font registered in step A3 from the graphic engine 202.
Step G3. The embedded font held by the graphic engine 202 is discarded.
Step A6. The application 201 notifies the graphic engine 202 via a GDI function that page printing is completed (the graphic engine 202 transfers the function to the printer driver 203 as in step A1).
Step Drv4. The printer driver 203 generates a PDL command for page end control.
Step A7. The application 201 notifies the graphic engine 202 via a GDI function that the print job is to be completed (the graphic engine 202 transfers the function to the printer driver 203 as in step A1).
Step Drv5. The printer driver 203 generates a PDL command for job end control.
The information stored in a font will be described in more detail below with reference to FIG. 8. A font contains primarily the following information.
Face Name
An identification name for identifying a font to be used.
Number of Glyph Definitions
The number of definitions of a glyph representing the shape of a character defined in a font.
Glyph Index Table
To use various character codes with a single font, a font such as TrueType or OpenType defines an identifier independent of a character code for each glyph in the font, thereby managing glyphs independently of character codes. This glyph identifier is generally called a glyph index. By preparing a correspondence table of character codes and corresponding glyph indices for each character code system, various character codes can be used with a single font. This correspondence table is called a glyph index table. FIG. 8 shows two glyph index tables. A common glyph index table has a data format in which a glyph index is extracted from a character code.
Glyph
Information representing the shape of a character. Bitmaps, paths, and curves are examples of a method of representing a glyph. Each defined glyph is identified by a font-dependent glyph index in a font. Since a glyph index is font-dependent, as shown in FIG. 8, a glyph index of “A” is 0x0001 in a “Gothic” font and is 0x0011 in an “Arial” font. Usually, a glyph index changes in accordance with a font even for the same character.
Like British pound in the “Gothic font” and “” and “” in the “Arial” font (alphanumeric font), some characters have no defined glyphs depending on fonts. When characters like these are to be printed, as shown on the right-hand side of FIG. 6, characters representing glyph-undefined characters such as “•” and “□” are printed in accordance with a designated font.
When an OS which supports only ShiftJIS as an internal character code is used, British pound cannot be displayed even by the “Arial” font in which the glyph of British pound is defined, because no definition of a ShiftJIS character code for British pound exists. For commercial uses of an OS, inability to display general symbols such as British pound (a character formed by adding a lateral bar to “L”) and a Euro symbol is unpreferable. Therefore, an OS exists which designates information for character drawing by using a font-dependent glyph index instead of a character code.
The operations of the application 201, the graphic engine 202, and the printer driver 203 when conventional glyph index printing is to be performed in a printing control apparatus using an OS which cannot use Unicode as an internal structure will be described below with reference to a sequence chart shown in FIG. 10. Note that the same reference numerals as in FIG. 9 denote the same processes in FIG. 10, and a repetitive explanation thereof will be omitted.
Steps A1 to Drv2 are the same as in FIG. 9.
Step A3. The application 201 uses Unicode to request character drawing which cannot be expressed by ShiftJIS.
Step G1. Since Unicode cannot be used in the OS, the graphic engine 202 looks up a glyph index table corresponding to a font of the character designated by Unicode, converts into a glyph index contained in the table and corresponding to Unicode, and transfers the glyph index as a character code of character drawing to the printer driver 203.
Step Drv3. To generate a character drawing command, the printer driver 203 acquires a character glyph by performing the following processing by using the glyph index.
Step Drv3.1. The printer driver 203 acquires a character glyph by designating the glyph index to the graphic engine 202.
Step G2. The graphic engine 202 acquires a glyph of the designated glyph index from the font data, and transfers the glyph to the printer driver 203.
The processing is completed by executing steps A6 and A7 as in FIG. 9.
The processing shown in FIGS. 9 and 10 is performed by a single process; when the application 201 calls a GDI function, those process routines of the graphic engine 202 and the printer driver 203, which are required to realize functions of the called GDI function start operating, thereby generating a PDL command corresponding to the contents of the call.
Since the GDI function call by the application 201 is completely linked to the processes by the graphic engine 202 and the printer driver 203, the operation procedure between the application 201, the graphic engine 202, and the printer driver 203 is assured. This ensures that a font is held by the graphic engine 202 in Step Drv3.1 Character Glyph Acquisition which is the processing step by the printer driver 203.
FIG. 4 is a functional block diagram of a host computer including a spooler and a despooler and its related functions in addition to the configuration shown in FIG. 3. Before printing data to be transmitted to a printer is generated, the spooler temporarily saves data in a data format (a so-called intermediate code) different from the printing data to be finally transmitted to the printer. From this data temporarily saved in the intermediate code format, the despooler generates the printing data to be finally transmitted to the printer. That is, in the host computer shown in FIG. 4, when a printing instruction is to be transmitted from a graphic engine 202 to a printer driver 203, a spool file 303 made up of intermediate codes is once generated. After that, the despooler converts this spool file into printing data and outputs the data to the printer.
In the host computer shown in FIG. 3 described earlier, the application 201 is released from the printing process when the printer driver 203 has completely converted all printing instructions from the graphic engine 202 into control commands of the printer 1500. In contrast, in the host computer shown in FIG. 4, the application 201 is released from the printing process when a spooler 302 has converted all printing instructions into intermediate code data and output the data to the spool file 303. Usually, the application 201 is released from the printing process within a shorter time period in the latter case (the configuration shown in FIG. 4).
Also, when the configuration shown in FIG. 4 is used, the contents of the spool file 303 can be processed before printing. This can realize functions which the application does not have, e.g., enlarged/reduced printing and N-up printing by which a plurality of (N) pages are printed as they are reduced into one page. Note that the spool file 303 is usually processed by performing settings from a window provided by the printer driver 203, and saving the set contents on a memory such as a RAM or HD by the printer driver 203.
From the above advantages, transition from the configuration shown in FIG. 3 to the configuration in which spooling is performed using intermediate code data as shown in FIG. 4 is advancing.
A process of printing font-embedded data in the host computer having the functional arrangement shown in FIG. 4 will be explained below with reference to FIG. 11.
This processing cannot be done by a single process, unlike the processing by the functional arrangement shown in FIG. 3. To control a plurality of jobs, queue processing between an application process and a despooler process must be realized. In practice, communication between these two processes is performed via a spool file manager 304. To simplify the explanation, however, the spool file manager 304 including the queue processing is regarded as one communication medium and omitted from FIG. 11 and from the following explanation.
Step A1. The application 201 notifies the graphic engine 202 via a GDI function that a print job is to be started (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to a dispatcher 301, and the dispatcher 301 transfers the contents to the spooler 302).
Step S1. The spooler 302 generates, in the spool file 303, a job file which holds information, such as a paper size, concerning the job, and activates a despooler 305 as another process.
Step D1. The despooler 305 reads the job file and calls a GDI function for starting the print job (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv1. The printer driver 203 generates a PDL command for job start control.
Step A2. The application 201 notifies the graphic engine 202 via a GDI function that page printing is to be started (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the spooler 302).
Step S2. The spooler 302 generates, in the spool file 303, a page file which holds information concerning a page.
Step A3. The application 201 registers an embedded font in application data into the graphic engine 202. This registration makes it possible to use information of the font essential to character drawing even in this environment.
Step G1. The graphic engine 202 holds the font information.
Step A4. The application 201 performs character drawing by using a font including the font registered in step A3 (the graphic engine 202 converts a GDI function called upon drawing into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the spooler 302).
Step S3. The spooler 302 writes information representing character drawing as an intermediate code into the page file of the spool file. This intermediate code contains only “character code, font attributes, and drawing attributes” obtainable from the DDI function, and does not contain any font.
Step A5. The application 201 deletes the font registered in step A3 from the graphic engine 202.
Step G3. The embedded font held by the graphic engine 202 is discarded.
Step A6. The application 201 notifies the graphic engine 202 via a GDI function that page printing is completed (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the spooler 302).
Step S4. The spooler 302 closes the page file and requests the despooler 305 to reproduce the page.
Step A7. The application 201 notifies the graphic engine 202 via a GDI function that the print job is to be completed (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the spooler 302).
Step S5. The spooler 302 closes the job file and notifies the despooler 305 that no more pages are present.
Step D2. The despooler 305 calls a GDI function for page start in order to reproduce the intermediate code described in the page file generated in step S2 (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv2. The printer driver 203 generates a PDL command for page start control.
Step D3. The despooler 305 calls a GDI function to reproduce character drawing described in the intermediate code (the graphic engine 202 converts the GDI function called upon drawing into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv3. To generate a character drawing command, the printer driver 203 acquires a character glyph by the following processing.
Step Drv3.1. The printer driver 203 acquires a character glyph from the graphic engine.
Step G4. The graphic engine 202 searches for a font having the face name designated in the font attributes. However, the font (which is embedded and originally not present in this environment) is already discarded in step G3, and so the glyph of this font cannot be transferred even if requested. Therefore, on the basis of a predetermined relationship a glyph is formed using an alternate font of a type close to the font whose glyph is requested, and the result is transferred to the printer driver 203.
Step D6. The despooler 305 notifies the graphic engine 202 via a GDI function that the page printing is completed (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv4. The printer driver 203 generates a PDL code for page end control.
Step D7. The despooler 305 notifies the graphic engine 202 via a GDI function that the print job is to be completed (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv5. The printer driver 203 generates a PDL command for job end control.
Processing when the host computer as a printing control apparatus shown in FIG. 4 prints font-embedded data by using an OS which cannot use Unicode as an internal structure is indicated by a sequence chart shown in FIG. 12.
As shown in FIG. 12, this processing cannot be performed by a single process as in FIG. 11 described above. To control a plurality of jobs, queue processing between an application process and a despooler process must be realized. In practice, communication between these two processes is performed via the spool file manager 304. To simplify the explanation, however, the spool file manager 304 including the queue processing is regarded as one communication medium and omitted from FIG. 12 and from the following explanation.
Also, the same reference numerals as in FIG. 11 denote the same processes in FIG. 12, and a repetitive explanation thereof will be omitted.
Processes in steps A1 to S2 are the same as in FIG. 11.
Step A3′. The application 201 uses Unicode to request character drawing which cannot be expressed by ShiftJIS.
Step G1′. Since Unicode cannot be used in the OS, the graphic engine 202 looks up a glyph index table corresponding to a font of the character designated by Unicode, and transfers to the printer driver 203 a glyph index corresponding to the designated character code (Unicode) as a character code of character drawing.
Step S3. The spooler 302 writes information representing character drawing as an intermediate code into the page file of the spool file. This intermediate code contains only “character code, font attributes, and drawing attributes” obtainable from the DDI function, and does not contain any font.
Steps A6 to Drv2 are the same as in FIG. 11.
Step D3′. The despooler 305 calls a GDI function to reproduce character drawing described in the intermediate code. The character code of this intermediate code contains a font-dependent glyph index code (the graphic engine 202 converts the GDI function called upon drawing into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv3′. To generate a character drawing command, the printer driver 203 acquires a character glyph by the following processing by using the glyph index as a character code.
Step Drv3.1′. The printer driver 203 acquires a character glyph from the graphic engine by using the glyph index.
Step G4′. The graphic engine 202 searches for a font having the face name designated in the font attributes. If a font having the designated face name exists, a glyph can be acquired by the font-dependent glyph index. However, if this font is an embedded font, the application 201 has discarded the font registered in the OS in some cases.
If a font having the designated face name does not exist on the graphic engine 202, a glyph is formed using another font of a close type by font replacement. When this font replacement is performed, it is highly likely that a glyph different from the character intended by the user is acquired if the glyph is acquired using a font-dependent glyph index.
After that, the processing is completed by executing steps D6 to Drv5 in the same manner as in FIG. 11.
As shown in FIGS. 11 and 12, the above processing is performed by the two processes, i.e., the application process and despooler process. It is not ensured that a font registered in the graphic engine 202 by the application 201 is present in the graphic engine 202 when a spool file is reproduced by the despooler.
If no embedded font is present in the graphic engine 202, font replacement occurs as explained in step G4, so the font designated by the intermediate data is replaced with another font. In the processing shown in FIG. 11, therefore, as indicated in the uppermost right row in FIG. 7, the data may be output in a shape different from the shape intended by the user. Also, in the processing shown in FIG. 12, it is highly likely that no intended character glyph is acquired by the use of a font-dependent glyph index. Furthermore, since not a character code but a font-dependent glyph index code is supplied to the printer driver 203, a font replacement function using a built-in font of the printer cannot be applied.
To avoid this problem, a method of performing bitmap replacement during spooling can be performed to prevent font replacement of step G4.
First, a possible operation as a printing process in which bitmap replacement is performed during spooling will be described with reference to FIG. 13.
Step A1. The application 201 notifies the graphic engine 202 via a GDI function that a print job is to be started (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the spooler 302).
Step S1. The spooler 302 generates, in the spool file 303, a job file which holds information, such as a paper size, concerning the job, and activates the despooler 305 as another process.
Step D1. The despooler 305 reads the job file and calls a GDI function for starting the print job (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv1. The printer driver 203 generates a PDL command for job start control.
Step A2. The application 201 notifies the graphic engine 202 via a GDI function that page printing is to be started (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the spooler 302).
Step S2. The spooler 302 generates, in the spool file 303, a page file which holds information concerning a page.
Step A3. The application 201 registers an embedded font in application data into the graphic engine 202. This registration makes it possible to use information of the font essential to character drawing even in this environment.
Step G1. The graphic engine 202 holds the font information.
Step A4. The application 201 performs character drawing by using a font including the font registered in step A3 (the graphic engine 202 converts a GDI function called upon drawing into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the spooler 302).
Step S3. The spooler 302 writes information representing character drawing as an intermediate code into the page file of the spool file. If the font attribute contained in this intermediate code is an embedded font, the following processing is performed to eliminate the difference between drawn characters resulting from font replacement.
Step S3.1. The spooler 302 acquires a character glyph from the graphic engine 202.
Step G2. The graphic engine 202 generates a character glyph from the font and transfers the generated glyph to the spooler 302.
Step S3.2. The spooler 302 uses the received character glyph to convert character drawing into bitmap drawing, and spools as an intermediate code.
Step A5. The application 201 deletes the font registered in step A3 from the graphic engine 202.
Step G3. The embedded font held by the graphic engine 202 is discarded.
Step A6. The application 201 notifies the graphic engine 202 via a GDI function that page printing is completed (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the spooler 302).
Step S4. The spooler 302 closes the page file and requests the despooler 305 to reproduce the page.
Step A7. The application 201 notifies the graphic engine 202 via a GDI function that the print job is to be completed (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the spooler 302).
Step S5. The spooler 302 closes the job file and notifies the despooler 305 that no more pages are present.
Step D2. The despooler 305 calls a GDI function for page start in order to reproduce the intermediate code described in the page file generated in step S2 (the graphic engine 202 converts the called GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv2. The printer driver 203 generates a PDL command for page start control.
Step D8. The despooler 305 converts the intermediate code, of bitmap drawing converted from character drawing, on the page file into a GDI function call (the graphic engine 202 converts the called GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv6. The printer driver 203 converts bitmap drawing into a PDL command.
Step D6. The despooler 305 notifies the graphic engine 202 via a GDI function that the page printing is completed (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv4. The printer driver 203 generates a PDL code for page end control.
Step D7. The despooler 305 notifies the graphic engine 202 via a GDI function that the print job is to be completed (the graphic engine 202 converts the notified GDI function into a DDI function and outputs this DDI function to the dispatcher 301, and the dispatcher 301 transfers the contents to the printer driver 203).
Step Drv5. The printer driver 203 generates a PDL command for job end control.
Next, a possible operation as a printing process in which bitmap replacement is performed during spooling in accordance with the processing shown in FIG. 12 will be described below with reference to FIG. 14. Referring to FIG. 14, the same reference numerals as in FIG. 13 denote the same processes, and a repetitive explanation thereof will be omitted.
Processes in steps A1 to S2 are the same as in FIG. 13.
Step A3′. The application 201 uses Unicode to request character drawing which cannot be expressed by ShiftJIS.
Step G1′. Since Unicode cannot be used in the OS, the graphic engine 202 looks up a glyph index table corresponding to a font of the character designated by Unicode, and transfers to the printer driver 203 a glyph index corresponding to the designated character code (Unicode) as a character code of character drawing.
After that, steps S3 to Drv5 are the same as in FIG. 13.
In the processing explained with reference to FIGS. 13 and 14, even if the printer driver 203 requests a glyph of an embedded font (which is not originally present), no font replacement by the graphic engine occurs. Basically, therefore, a character output having a shape intended by the user is obtained. However, the conversion from character drawing into bitmap drawing has the following problems.
1. Deterioration of Quality Upon Enlargement
As indicated in the middle right row in FIG. 7, the quality of a character deteriorates if enlargement is performed after spooling.
2. Problem of Color Processing
Information concerning character drawing disappears when the data is converted into a bitmap. Therefore, color processing of character drawing cannot be applied to color conversion performed during color printing.
3. Problem of Compression
A compression process effective to a bitmap of a character glyph cannot be applied.
As described above, the conventional printing control apparatus includes a spooler, despooler, and printer driver. Before printing data to be transmitted to a printer is generated, the spooler temporarily saves data in a data format (a so-called intermediate code) different from the printing data to be finally transmitted to the printer. From this data temporarily saved in the intermediate code format, the despooler generates the printing data to be finally transmitted to the printer. The printer driver generates printer control commands. When character drawing using an embedded font is to be performed in this printing control apparatus, font replacement or bitmap replacement occurs. When the font replacement occurs, no intended output result can be obtained. When the bitmap replacement occurs, the printing quality lowers, and problems arise in color processing and in a compression process.
Also, when a code (glyph index) which identifies a font-dependent code is used instead of a character code, the character may be garbled if font replacement occurs in the despooler. Additionally, a font-dependent glyph index is not a character code and hence cannot be converted into a character code usable by a built-in font of the printer. Therefore, a process of replacement to a built-in font of the printer cannot be applied.